Fixes the root cause of wolverine#2991 / wolverine#2992: "HTTP endpoints resolve services wrong in codegen, but works in tests."

Root cause

The runtime type loader applies a per-ICodeFile service-provider override:

DynamicTypeLoader.Initialize / CompileAndAttach:
  if (serviceVariables != null && file.TryReplaceServiceProvider(out var sp))
      serviceVariables.ReplaceServiceProvider(sp);

So a Wolverine HTTP endpoint configured with ServiceProviderSource.FromHttpContextRequestServices resolves its service-located dependencies from httpContext.RequestServices.

The CLI codegen paths in DynamicCodeBuilder (WriteGeneratedCode / generateCode / TryBuildAndCompileAll) call generatedAssembly.GenerateCode(services) without that step. So dotnet run -- codegen write produced different and wrong code than the runtime: an opaque scoped lambda-factory dependency fell back to a created serviceScope, while a sibling DbContext used httpContext.RequestServices → two different scoped instances for one logical request.

Fix

Apply the override per file in all three CLI loops via a shared applyServiceProviderOverride(file, services).

The non-obvious part (regression guard)

The runtime path registers IServiceVariableSource as transient (fresh per file), so its ReplaceServiceProvider is naturally isolated. The CLI reuses one shared instance across every file, and ServiceCollectionServerVariableSource latches _replacedServiceProvider = true permanently (StartNewMethod only re-creates the default scope while it is false). So naively applying the override in the loop would leak httpContext.RequestServices into every subsequent file — non-HTTP message handlers, IsolatedAndScoped endpoints, etc.

The helper therefore calls a new IServiceVariableSource.ResetServiceProvider() (default no-op; implemented on ServiceCollectionServerVariableSource) before each file, so each file's override is isolated.

Tests

• New DynamicCodeBuilderTests.per_file_service_provider_override_is_isolated_to_its_own_file: an HTTP-style file (opts into the override) followed by a plain file, asserting the call sequence reset, replace, reset — i.e. the plain file does not inherit the override.
• All 399 CodegenTests pass on net9.0 + net10.0.

Verified downstream

Built WolverineWebApi (the #2992 repro) against this (local 2.2.8) and ran codegen write: the repro endpoint now resolves the opaque scoped service and the DbContext both from httpContext.RequestServices, and no non-HTTP MessageHandler file references httpContext.RequestServices (reset isolates correctly).

Bumps JasperFxVersion to 2.2.8.

Note: this changes codegen write/preview/test output for any consumer using a ServiceProviderSource override, so the downstream Wolverine PR (pin bump + de-skipping the #2992 repro) should run the full Wolverine suite to confirm no regressions.

🤖 Generated with Claude Code